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Verfahren und Vorrichtung zu einer schnellen 
Durchfiihrung von Netzwerkoperationen 

5 

Die Erfindung betrifft ein Verfahren und eine Vorrichtung 
zu einer schnellen Durchfiihrung von Netzwerkoperationen uber 
ein durch hohe Verzogerungszeiten charakterisiertes Netzwerk. 

10 Beispielhaf t fur ein Netzwerk mit hohen Verzogerungszeiten 
steht das GSM (Global System for Mobile Conmiunication) 
Netzwerk. Das GSM Netzwerk ist ein digitales Mobilf unknetz , 
bei dem die nutzbare Datenubertragungsrate 9.6 kBit/s pro 
Kanal betragt. Im Vergleich zu heutigen Festnetzen, wie 

15 beispielsweise dem ISDN (Integrated Service Digital Network), 
dessen Ubertragungsrate 64kBit/s erreicht, ist die Datenrate 
von GSM gering. Daher beeinflusst eine GSM-Verbindung in 
einer heterogenen Netzwerkverbindung, das heiSt in einer 
Verbindung, die iiber mindestens zwei verschiedene Netzwerke 

20 verlauft, sehr stark den absoluten Durchsatz der gesamten 

Verbindung, Dies stellt sich als besonders problematisch dar, 
wenn eine Verbindung von einem GSM-Benutzer zu einem Internet 
Service Provider (ISP) zwecks eines sogenannten Web- Surf ens 
oder/und Herunterladen von Daten aus dem Internet aufgebaut 

25 ist. In diesem Szenario stellt die GSM-Verbindung den 

kritischen Teil der Verbindung im Bezug auf die effektive 
Ubertragungsrate dar. 
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Der Austausch von Infonaationen zwischen den kommunizi erenden 
Partnerinstanzen, in diesem Fall zwischen dem GSM-Endgerat 
und dem Internet Service Provider (ISP), basiert auf einem 
ftir die Internet Anwendungen standardisierten 

Protokollstapel, dem sogenannten TCP/IP (Transmission Control 
Protokoll /Internet Protokoll) Protokollstapel. Dieser 
Protokollstapel besteht aus funf Protokollschichten, im 
weiteren auch als Schichten bezeichnet . Die oberste Schicht, 
die Anwendungsschicht beinhaltet die Anwendungen, die von 
einem Benutzer direkt genutzt werden, beispielsweise gehort 
das Surfen im Internet zu einer mSglichen dem Benutzer zur 
Verfugung stehenden Anwendung. Direkt unter der 
Anwendungsschicht ist eine Transportschicht mit den die 
Aufgaben dieser Schicht erfiillenden Transportprotokollen, wie 
beispielsweise das TCP (Transmission Control Protokoll) oder 
das UDP (User Datagramm Protokoll) angeordnet. Das Internet 
Protokoll (IP) als Beispiel bildet die Netzwerkschicht . Die 
zwei untersten Schichten, die Sicherungsschicht und die 
Bittibertragungsschicht, kSnnen unter dem Begriff 
netzwerkorientierte Schicht zusammengef afit werden, denn sie 
sind in Abhangigkeit von dem darunterliegenden Netz 
spezifisch definiert. 



25 



Die Aufgabe einer Schicht besteht unter anderem in der 
Aufarbeitung der empfangenen oder der zu iibertragenden Daten. 
Hierbei erfolgt die Kommunikation einer Schicht 
ausschlieSlich mit den direkt benachbarten Schichten. Die zur 
Ubertragung bereitgestellten Daten werden von einer Schicht 
zu der direkt darunterliegenden Schicht Qbergeben. Hierbei 



P11901-MAZ 



1999-11-26 



I13|12-199a 



:EP9at24727Jft^ 



3 



wird unter anderem eine Formatierung der Daten vorgenommen . 
Haufig iiberschreiten namlich die Daten der Anwendungsschicht 
die GroSe der Pakete, die uber eine physikalische Verbindung 
ubertragen werden konnen. Aus diesem Grund erfolgt eine 
5 Aufteilung einer Nachricht in kleinere Datenpakete, die 

auf einanderf olgend fiir eine Ubertragung angeordnet werden. 
Die Aufteilung der Daten ist ein Bestandteil der 
Formatierung. Die Formatierung der Daten wird auf jeder 
Protokollschicht durchgefuhrt . Die Formatierung der Daten 

10 beinhaltet insbesondere das Hinzufugen der fur jede 

Protokollschicht charakteristischen Kontrolldaten . Meistens 
werden die Kontrolldaten am Anfang eines Datenpaketes in Form 
des sogenannten Kopffeldes oder/und am Ende in Form des 
sogenannten Endefeldes anhangt. Die tatsachlichen Daten sind 

15 in dem Nutzdatenf eld en thai ten. Diese Kontrolldaten sind fur 
jede Schicht charakteristisch definiert und standardisiert , 
denn nur auf diese Weise kann eine einheitliche Kommunikation 
zwischen zwei Partnerinstanzen gewahrleistet werden. Fur die 
vorliegende Erfindung sind bestimmte Kontrolldaten des TCP 

2 0 von Bedeutung . 

Das Transportprotokoll TCP leistet einen zuverlassigen 
Transportdienst fiir einen Bytestrom zwischen zwei 
Kommunikationspartnern. Zuverlassigkeit ist hier im Sinne von 
25 Fehlerf reiheit , Reihenf olgetreue und Schutz vor 

Datenverlusten und Duplikaten zu verstehen. Der zu 
libertragende Bytestrom, der von der Anwendungsschicht an die 
TCP- Schicht ubergeben wird, wird von dem TCP in Segmente 
unterteilt, welche dann als IP-Datagramme ubertragen werden. 

P11901-MAZ 1999-11-26 
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Ein IP-Datagramm bezeichnet ein Datenpaket, das nach den 
Regeln des IP-Protokolls formatiert wird. Die Eigenschaft der 
Datagramme ist, daS der Datenaustausch, der durch den Einsatz 
der Datagramme realisiert wird, nicht zuverlassig ist. Somit 
wird vom IP keine Garantie gegeben, dag ein Paket in der Tat 
zu einem Empf anger geliefert wird. Ebenfalls kOnnen IP- 
Datagramrae in der Reihenfolge vertauscht oder dupliziert beim 
Empf anger ankommen. In diesem Konzept ist es aber die Aufgabe 
von TCP, die fehlerhafte Ubertragiing zu erkennen und die 
aufgetretenen Fehler zu beheben. Die IP-Datagramme werden 
weiterhin aufgrund des Hierarchieprinzips der direkt 
darunterliegenden Schicht Qbermittelt. 

Zur Realisierung der gestellten Aufgaben wurde in das TCP 
15 eine Reihe aufwendiger Mechanismen eingebaut. Auf die 
einzelnen Mechanismen, wie zum Beispiel den 
Penstermechanismus, das kumulative Bestatigungsschema, den 
sogenannten S low- S tart -Algorithmus oder einen Algorithmus zur 
Vermeidiong von Stauungen, den sogenannten Congestion 
Avoidance Algorithmus wird hier nicht naher eingegangen. Die 
genaue Beschreibung dieses Verfahrens kann aus "TCP/IP. 
Illustrated, Volume 1" von W. Richard Stevens entnommen 
werden . 



20 



25 



Ein wichtiger Mechanismus, der an dieser Stelle genauer 
betrachtet wird, hSngt mit dem Verbindungsaufbau bei TCP 
zusammen. Bei einem Aufbau einer Verbindung verwendet TCP den 
sogenannten Dreiweg-Algorithmus , der den Austausch von fest 
definierten Signalisierungsinf ormationen sicherstellt . Der 
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Sachverhalt kann aus der Figur 2 entnommen warden. Die 
kommunizierenden Partner werden unter den Namen Klient und 
Server gefasst. Hierbei ist der Klient die Einheit, die die 
Koininunikation initiiert und der Server die jenige, die die 
5 Verbindung entgegennimmt . Insgesamt wird fur den 

Verbindungsaufbau zwischen dem Klient und dem Server ein 
Austausch von drei Nachrichten erf orderlich . Mit Versenden 
der ersten Nachricht werden die anfanglichen Sequenznummern 
zwischen den kommunizierenden Partnern vereinbart. Die 

10 Datenpakete, die ausgetauscht werden, sind durch eine 
eindeutige Nummer, die sogenannte Sequenznummer 
identif iziert . Zu diesem Zweck ist in einem Header eines TCP- 
Datenpakets ein Feld vorgesehen, das zur Synchronisation der 
Sequenznummern beim Verbindungsaufbau dient, das sogenannte 

15 SYN-Flag, in Figur 2 als SYN bezeichnet. Ist der Server 

bereit, die Verbindung entgegenzunehmen , antwortet er mit 
einer Nachricht, die das gesetzte SYN-Flag und eine 
Bestatigung fur die anfangliche Sequenznummer des Klients 
enthalt ACK(SYN) , Schliefilich sendet der Klient eine 

2 0 Nachricht mit der Bestatigung fur die SYN-Nachricht des 

Servers ACK(SYN) . Nach dem Austausch der drei Nachrichten ist 
die Verbindungsaufbauphase abgeschlossen . Im nachsten Schritt 
erfolgt die Ubertragung der Daten, somit die tatsachliche 
Kommunikation, die durch einen Verbindungsaufbau 

25 abgeschlossen wird. Der Verbindungsabbau benotigt einen 

Austausch von vier Nachrichten. Zuerst wird eine Nachricht 
vom Klient an den Server mit dem gesetzten FIN-Flag (FIN) , 
das die SchlieSung der Verbindung in die gesendete Richtung 
bewirkt, verschickt. Auf diese Weise initiiert der Klient den 
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Verbindungsabbau. Der Server bestatigt den Empfang dieser 
Nachricht mit ACK(FIN) und leitet ebenfalls die 
SchlieSungsphase ein. Zu diesem Zweck verschickt dieser die 
Nachricht mit dem gesetzten FIN-Flag (FIN) an den Klient und 
dieser antwortet mit ACK(FIN) . Nach diesem 
Nachrichtensaustausch ist der Verbindungsabbau beendet . 

insgesamt werden ftir den Verbindungsaufbau und -abbau minimal 
sieben Nachrichten, oder dreieinhalb sogenannte RTT (Round 
Trip Time) benotigt . Ein RTT bezeichnet eine Zeitspanne 
zwischen dem Verschicken einer Anf ragenachricht und dem 
Empfang der dazugehSrigen Antwortnachricht . Diese Zeit 
variiert entsprechend in Abhangigkeit von der 
Ubertragungsrate des zugrundeliegenden Netzes . 

Viele Anwendungen basieren jedoch auf einer einfachen 
Interaktion zwischen den kommunizierenden Partnerinstanzen . 
Beispielhaft ftir eine einfache Interaktion steht die 
sogenannte Transaktion, bei der ein Klient eine 
Anfragenachricht an den Server verschickt und der EmpfSnger 
mit einer Antwortnachricht dem Sender die angef orderten 
informationen zusendet. Diese Art von Datenaustausch ist 
beispielsweise im Internet zu finden, der durch ein 
transaktionsorientiertes Verkehrsmuster des World Wide Web 
Protokolls charakterisiert ist. Die Transaktionen im Internet 
werden vorwiegend aufgrund des verwendeten HTTP Protokolls 
veranlaSt . 
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Bei der derzeit eingesetzten Protokollversion HTTP/1,0, RFC 
1945 "Hypertext Transfer Protocol -- HTTP/1.0" von T. 
Berners-Lee, R. Fielding und H. Frystyk, May 1996, wird fur 
jedes angeforderte Objekt einer WWW-Seite, zum Beispiel ein 
5 Textblock oder ein Bild, zunachst eine TCP-Verbindung 

aufgebaut. Erst dann wird eine Transaktion durchgef uhrt . Das 
heiSt der Sender sendet eine Anf ragenachricht , die sogenannte 
Request Message an den Empfanger und dieser verschickt die 
angef orderten Daten mit einer Antwortnachricht , mit der 

10 sogenannten Response Message. AnschlieSend wird die TCP- 
Verbindung wieder geschlossen. Dieser Sachverhalt hat einen 
erheblichen Einfluss auf die gesamte Leistung einer Sitzung, 
wenn fur jedes Objekt, sei es nur ein kleines Bild-Objekt, 
eine explizite Verbindung aufgebaut werden muss, die auf dem 

15 Dreiweg-Algorithmus basiert, der wiederum inindestens drei 

Nachrichten ftir den Aufbau und vier fur den Abbau benotigt. 

Die Aufgaben, die das TCP zu erfullen hat, weisen bereits 
darauf hin, dafi TCP fur Netzwerkgegebenheiten konzipiert 

2 0 wurde, die durch schnelle Datenubertragung und durch geringe 
Ubertragungsstorungen charakterisiert sind, wie dies bei den 
drahtgebundenen Datennetzen der Fall ist. Diese Annahmen 
werden jedoch im GSM nicht erfullt und das ist eine Ursache 
fur eine nicht optimale Funktionalitat von TCP in dieser Art 

25 von Netzen. Eine Reihe von Dokumenten stellt Konzepte dar, 
die sich mit Optimierung von TCP fur Netze mit geringer 
Ubertagungskapazitat auseinandersetzen. Im folgenden wird 
beispielhaft eine Losung vorgestellt. 
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in „T/TCP - TCP Extensions for Transactions Functional 
specification" RFC 1644 von R. Braden wird ein Konzept 
verges tellt, mit dem insbesondere die Verbindungsaufbauphase 
optimiert wird. Zu diesem Zweck werden Inf ormationen 
beztiglich der Verbindung zu einem bestimmten Server 
zwischengespeichert . Auf diese Weise wird der komplette 
Dreiweg-Algorithmus ausschlieSlich beim erstmaligen 
Verbindungsaufbau zu einem Server durchgef tihrt und die 
informationen bezuglich der Konf iguration der Verbindung, die 
wahrend dieses Verbindungsaufbaus vereinbart werden, werden 
zwischengespeichert. Bei nachf olgenden Zugriffen zu dem 
gleichen Server wird die vollstandige Verbindungsaufbauphase 
xmtgangen indem die Konf iguration aus den gespeicherten 
Informationen entnoininen wird. 

Der Nachteil dieser Losung ist jedoch eine nicht vorhandene 
Transparenz beztiglich der Anwendungen. Die Realisierung 
dieses Konzeptes erfordert namlich die Verdnderung von 
Systemaufrufen in einer Anwendung. Beispielsweise wird ein 
schnellerer Verbindungsaufbau erzielt bei Ersetzung von den 
Systemaufrufen "connect" und "send" durch "sendto". Diese 
Systemaufrufe sind Bestandteile der sogenannten Socket- 
Programmierschnittstelle, deren genauere Funktionalitat aus 
der unten aufgeftihrten Beschreibung zu entnehmen ist. 

DemgemaiS ist es die Aufgabe der vorliegenden Erf indung eine 
Methode und eine Vorrichtung zu schaffen, die eine effiziente 
Durchftihrung von Transaktionen zwischen zwei kozmnunizierenden 
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Einheiten liber eine Ubertragungsstrecke, die durch hohe 
Verzogerungszeiten charakterisiert ist, realisiert. 

Dies wird erf indungsgemaS gelost durch die Lehre des 
5 Patentanspruches 1 und durch die Lehre des Patentanspruches 
16. 

Vorteilhaft erweist sich hierbei, dag die Optimierung der 
Durchftihrung der Transaktionen einen unmittelbaren Einfluss 
10 auf die Leistungsf ahigkeit der Anwendungen hat, denn durch 
eine schnelle Durchfuhrung der Transaktionen wird eine 
stabilere Arbeitsweise von verzogerungsempf indlichen 
Anwendungen gewahrleistet . 

15 Ein weiterer Vorteil besteht in der Unabhangigkeit der 

Realisierung der Erfindung sowohl von der Anwendungsschicht 
als auch von der Transportschicht , denn es wird 
gewahrleistet, daS das Einbinden der Erfindung fur die beiden 
Schichten transparent bleibt, 

20 

Weitere vorteilhafte Ausgestaltungen der Erfindung ergeben 
sich aus den Patentansprtichen 2 bis 15 und den 
Patentanspruchen 17 und 18 . 

2 5 Im folgenden wird die Erfindung anhand von 

Aus fiihrungsbei spiel en und Figuren naher erlautert . 

Folgende Figuren zeigen: 
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Fig.l: Ablaufdiagramm des erf indungsgemaSen Verfahrens, 
Fig. 2: Schematische Darstellung des 3-Wege Algorithmus, 
Fig.: Darstellung eines Verbindungsaufbaus gemaS 

3a) des Stands der Technik 

3b) der Erfindung, und 
Fig. 4: Darstellung einer beispielhaf ten Implementi erung 

Im folgenden wird die Erfindung anhand der Figur 1 und des 
Patentanspruches 1 erlautert . 



GemSE Figur 1 ruft eine Anwendung 1 einen Systemauf ruf 2 auf . 
Dieser wird im Schritt 3 einem Modul, einem sogenannten 
Pipelinemodul iibergeben. Die erste Aufgabe des Pipelinemoduls 
besteht in einer Ermittlung des Systemauf ruf es 4 bezuglich 

15 seines Ausftihrungsmodus , das heiSt ob es sich urn einen 

blockierenden oder einen nicht-blokierenden Systemaufruf 
handelt. Wenn das Pipelinemodul den Systemaufruf als einen 
blockierenden Auf ruf erkennt, dann wird auf eine bekannte 
Weise fortgefahren. Das heifit eine Netzwerkoperation wird 

20 ausgelost 5 und die aufrufende Anwendung bleibt blockiert 6 
bis ein Resultat der ausgelosten Netzwerkoperation 
zuruckgeliefert wird 7. Der blockierende Zustand der 
Anwendung ist in der Figur 1 dadurch erkennbar, daS aus dem 
blockierenden Ausftihrungsmodus kein Pfeil zu der Anwendung 

25 zurtickftihrt, sondern es wird ausschlieSlich eine 

Netzwerkoperation ausgelost 5. Im Falle eines nicht- 
blockierenden Systemauf ruf es wird an die Anwendung 
unmittelbar ein logischer Wert zurtickgegeben 8. Mit diesem 
Schritt wird ermsglicht, dafi die Anwendung mit den folgenden 
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Programmschritten fortfahrt, ohne, dag diese blockiert 
bleibt, urn das Resultat des bei der Partnerinstanz 
tatsachlich durchgef uhrten Systeitiauf ruf s abzuwarten. Der 
Ausdruck unmittelbar bezieht sich hiermit auf die Zeit, die 
gebraucht wird, um den logischen Wert in der die 
Netzwerkoperation initiierenden Einheit zu ermitteln. Da dies 
in dieser Einheit lokal gemacht wird, ist diese Zeit 
erheblich geringer als die Zeit, die fur die Ubertragung der 
Netzwerkoperation liber ein Netzwerk, fur die Durchf uhr\ing des 
Systemaufrufes in der Partnerinstanz und fur die Lieferung 
und Empfang des Resultates benotigt wird. 



Mit der unmittelbar en Ruckgabe des logischen Wertes im Falle 
eines nicht-blockierenden Ausftihrungsmodus erfolgt ebenfalls 

15 die Auslosung einer Netzwerkoperation 5. Dies geschieht 
entweder kurz vor der Ruckgabe des logischen Wertes oder 
direkt danach. Bei den nicht-blokierenden Systemauf ruf en wird 
in dem Pipelinemodul ebenfalls auf das Resultat der 
ausgelosten Netzwerkoperation gewartet 6, dies geschieht 

2 0 jedoch unabhangig von der laufenden Anwendung. Nach dem 
Empfangen eines Resultates wird dieses untersucht und 
entsprechend bezuglich des Ausf uhrungsmodus und des 
zuruckgelief erten Wertes behandelt 9. 

25 Im folgenden wird beispielhaft die Behandlung der empfangenen 
Resultate dargestellt. 

Zuerst wird ein empfangenes Resultat auf den Ausf uhrungsmodus 
untersucht. Wenn es sich um ein Resultat eines nicht- 
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blockierenden Systemauf ruf es handelt, dann bedeutet das, daS 
die Anwendung zu diesem Zeitpunkt lauft und nicht blockierend 
auf ein Resultat wartet . Aus diesem Grund wird das empfangene 
Resultat abgespe i chert . Als nachstes wird das Resultat 
bezuglich seines Wertes untersucht, das heifit, ob es sich um 
ein negatives oder ein positives Ergebnis handelt . Beim 
Eintreten eines negativen Resultates wird dies beispielsweise 
mittels eines speziellen Vermerks markiert, um auf diese 
Weise die Notwendigkeit der Fehlermeldung an die Anwendung 
kenntlich zu machen. Ein negatives Resultat bedeutet das 
Auftreten eines Fehlers, beispielsweise ein Abbruch einer 
Verbindung und dieser Sachverhalt muss der laufenden 
Anwendung mitgeteilt werden. Die sicherste Ausfiihrbarkeit der 
Erfindung, in Anbetracht der Fehlermeldung, ist 
gewahrleistet, wenn die Fehlermeldung so frtih wie moglich 
erfolgt. Aus diesem Grund ist es am besten bei jedem 
Systemaufruf zuerst zu tiberpriifen, ob negative und bis zu 
diesem Zeitpunkt nicht gemeldete Resultate vorheriger Aufrufe 
abgespeichert sind. Wenn diese fjberprafung feststellt, da£ 
ausstehende negative Resultate vorhanden sind, dann werden 
diese als Riickgabewert bei dem gerade ausfahrenden 
Systemaufruf an die Anwendung, in Form eines logisch 
negativen Wertes zuruckgelief ert . 

Ein ahnlicher Ablauf bezuglich des Rtickgabewertes findet bei 
einem Resultat statt, das eine Antwort auf eine sich im 
blockierenden Zustand befindende Anwendung enthalt. In diesem 
Fall wird ebenfalls zuerst tiberprtift, ob negative und bis zu 
diesem Zeitpunkt nicht gemeldete Resultate abgespeichert 
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sind. Wenn diese Uberprufung feststellt, dag ausstehende 
negative Resultate vorhanden sind, dann warden diese als 
Ruckgabewert in Form eines logisch negativen Wertes der 
Anwendung zuruckgelief ert . Im Falle jedoch, daS keine 
negativen Resultate zu verzeichnen sind, wird der aktuell 
empfangene Wert an die Anwendung zuruckgegeben . 

Theoretisch spricht man von Nachrichten in Form von 
Datenpaketen, die versendet werden, urn beispielsweise eine 
Verbindung aufzubauen. Praktisch kann dies beispielhaft mit 
einer Programmierschnittstelle, die eine Umwandlung der 
Programmierbef ehle der Anwendungsschicht zu 
Netzwerkoperationen einer Netzwerkschicht durchfuhrt, 
realisiert werden. Diese Programmierbef ehle konnen als 
Systemauf ruf e ausgefuhrt werden, die dem Benutzer 
ermoglichen, auf die Netzwerkdienste zuzugreifen. 

Ein Netzwerkdienst wird formal durch eine Reihe von 
Dienstelementen oder Netzwerkoperationen gekennzeichnet , uber 
die es dem Anwender moglich ist, den Dienst in Anspruch zu 
nehmen. Diese Dienstelemente sorgen zum Beispiel dafur, daS 
der Dienst eine bestimmte Handlung durchfuhrt oder daS dieser 
auf eine Handlung der Partnerinstanz in bestimmter Weise 
reagiert. Innerhalb eines Protokollstapels wie beispielsweise 
25 TCP/IP Oder OSI (Open Systems Interconnection) werden 
verschiedene Dienstelemente unterschieden, Diese 
Dienstelemente sorgen dafur, daS ein Dienst eine bestimmte 
Handlung durchfuhrt. Zum Beispiel wird der Aufbau einer 
Verbindung mittels des Dienstelementes "Anf orderung" , die 
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sogenannte request, und der Handlung "Aufbau", das sogenannte 
CONNECT initiiert. Die entsprechende Nachricht hat in der 
OSI-Schreibweise das Format CONNECT. request . Wenn diese 
Anforderung erledigt worden ist, bekommt die Partnerinstanz 
uber eine Anzeige, die sogenannte indication, ein Signal, mit 
dem eine Aktion angekundigt wird. Beispielsweise erhalt die 
angesprochene Partnerinstanz nach einem CONNECT. request eine 
CONNECT. indication, dann bedeutet dies, da£ der Aufbau einer 
Verbindung gewunscht ist. Diese Instanz verwendet dann eine 
Antwortnachricht, die sogenannte response, in diesem Fall ist 
es CONNECT. response, urn auf diese Weise mitzuteilen, ob diese 
die Verbindungsaufforderung annehmen oder ablehnen will. Die 
Partnerinstanz, die das ursprangliche CONNECT . request 
ausgegeben hat, erfahrt mittels einer Bestatigung, der 
sogenannten CONNECT. confirm, die Bereitschaft der 
Partnerinstanz. Das angegebene Beispiel bezieht sich auf 
einen Verbindungsaufbau, der durch CONNECT initiiert wird. 
Vergleichbare Dienstelemente sind ebenfalls ftir andere 
Operationen, wie beispielsweise das Senden der Daten (SEND) , 
definiert, auf die an dieser Stelle nicht genauer eingegangen 
wird. Das angegebene Beispiel zeigt jedoch, daS die 
Aufftihrung der Netzwerkoperationen sehr abstrakt ist. Aus 
diesem Grund wurde beispielsweise fur das Betriebssystem Unix 
4.3BSD eine einheitliche Programmierschnitts telle ftir den 
systemunabhSngigen Zugriff auf Netzwerkdienste, die 
sogenannte Socket-Schnittstelle eingefuhrt. Dies 
gewahrleistet eine abersichtlichere Auffuhrung der 
Dienstelemente. Die Initiierung einer Nachricht bedeutet 
dabei im konkreten Sinne die Auffuhrung von 
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Programmierbef ehlen auf der Anwendungsebene , Die Socket- 
Schnittstelle ftihrt dann die Umwandlung der 

Programmierbef ehle, die im folgenden als Systemauf ruf e oder 
Aufrufe bezeichnet werden, in die Dienstelemente durch. Im 
5 weiteren wird diese Programmierschnittstelle zu Zwecken der 
Erlauterxing der Erfindung beispielhaft eingesetzt. 

Die Socket-Programmierschnittstelle besteht aus einem Satz 
von Systemauf ruf en, die sich jeweils auf einen sogenannten 

10 Socket beziehen. Konzeptionell stellt ein Socket einen 

Kommunikationsendpunkt dar^ an den auf der einen Seite eine 
Netzwerkverbindung und auf der anderen Seite eine Anwendung 
angebunden ist. Die wichtigsten Systemauf ruf e werden im 
folgenden naher aufgefuhrt. Mit einem Systemauf ruf socket 

15 wird ein neuer Socket erzeugt. Dabei werden als Parameter das 
AdreSformat, der Typ des Sockets und das Protokoll 
spezif iziert . Fur eine TCP Verbindung wird beispielsweise 
Internet -Adre&format, verbindungsorientierter Sockettyp und 
TCP/IP-Protokoll gewahlt. Durch den Systemauf ruf connect 

2 0 fordert eine Anwendung eine Verbindung zu einem entfernten 
Socket im Netz an. Hierbei wird der lokale Socket und die 
Adresse des entfernten Sockets als Parameter angegeben. Jede 
Verbindung ist demnach durch ein Paar von Sockets eindeutig 
gekennzeichnet . Das eigentliche Senden von Daten erfolgt 

2 5 durch den Auf ruf send und das Lesen von empfangenen Daten 
durch den Auf ruf recv. Es gibt noch einige weitere 
Systemaufrufe als die an dieser Stelle beispielhaft 
erwahnten, welche jedoch hier der Ubersichthalber nicht 
genauer aufgefuhrt werden. 
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Die Systemaufruf e warden mittels einer 
Programmierschnittstelle in die Netzwerkoperationen 
iimgesetzt. Das bedeutet, daS beispielsweise das Ausfiihren 
eines Aufrufes connect die Einleitung des Dreiweg-Algorithmus 
veranlasst. Der Benutzer hat keinen direkten Einfluss auf die 
Durchfahrung der Netzwerkoperation . Der Zugriff auf die 
Netzwerkoperationen kann aber von einem Benutzer mittels der 
Systemaufruf e gesteuert warden. Urn die Modifikation 
bestehender Anwendungen zu vermeiden, ist es demgemaS 
Gegenstand der Erfindung zwischen den Systemaufruf en und den 
Netzwerkoperationen eine zusatzliche Schicht einzubauen, die 
eine transparente Umsetzung der beiden Arten von Operationen 
veranlasst, ohne dabei die Implementation der Anwendxmg zu 
15 verandern. Die Aufgabe dieser zusatzlichen Schicht, die im 
weiteren als Pipelinemodul bezeichnet wird, ist es, die von 
einer Anwendung erhaltenen Systemaufruf e zu interpret ieren 
und entsprechend auf zuarbeiten . 



10 



20 



25 



Die hauptsachliche Aufgabe des Pipelinemoduls liegt jedoch in 
der Ermittlung des Ausf tihrungsmodus eines Systemaufruf es , das 
heist in der Entscheidung, ob ein Ergebnis eines 
Systemaufrufes unmittelbar an die Anwendung tibergeben werden 
kann, oder ob die Anwendung auf den tatsachlichen Wert der 
bei einem Seirver durchgefiihrten Operation warten muss. Im 
ersten Fall ist die Rede von einem nicht blockierenden 
Systemaufruf und im zweiten Fall, bei dem die Anwendung einen 
tatsachlichen Wert der durchgef uhrten Operation erwartet, 
handelt es sich um einen blockierenden Systemaufruf. Dies 
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bedeutet, daS das Pipelinemodul die Unterscheidung zwischen 
den beiden Arten von Systemauf ruf en vornehmen muss, was auf 
folgende Weise realisiert wird. Wenn der Ruckgabewert einen 
logischen Aussagewert hat, das heiSt, wenn bei einer 
5 erfolgreich durchgefuhrt Operation eine 1 fur wahr und bei 
einer nicht erfolgreich realisierten Operation eine 0 fur 
falsch zuruckgegeben wird, dann erkennt eine Anwendung, daS 
es sich uiti einen nicht-blockierenden Aufruf handelt und dies 
impliziert einen unmittelbaren Ruckgabewert an die Anwendung. 

10 Nach Erhalt des Wertes setzt die Anwendung mit der Ausfuhrung 
der nachsten Operationen fort. Der Status der schwebenden 
Operation, das heiSt der Operation, die an einen Server 
verschickt wurde, von der aber noch kein tatsachlicher Wert 
erhalten wurde, wird im Pipelinemodul zwischengespeichert . 

15 Das Abspeichern des Status ist notwendig, damit nach Erhalt 
des tatsachlichen Wertes dieser von dem Pipelinemodul einer 
sich im schwebenden Zustand befindenden Operation zugeordnet 
werden kann. 

20 Bei einem blockierenden Systemauf ruf , der dadurch 

gekennzeichnet ist, daS als Ruckgabewert des Systemauf ruf s 
Daten und nicht logische Werte erwartet werden, wird von dem 
Pipelinemodul kein unmittelbarer Wert an die Anwendung 
zuruckgegeben, sondern es wird gewartet bis die tatsachlichen 

25 Daten empfangen werden. Wahrenddessen bleibt die Anwendung 
blockiert. AuSer bei denjenigen Systemauf ruf en, die keinen 
logischen Ruckgabewert, sondern Daten zurucklief em, muss von 
dem System sichergestellt werden, daE zusatzlich der letzte 
Systemaufruf einer Verbindung ebenfalls in einen 
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blockierenden Zustand versetzt wird, denn nur auf diese Weise 
wird das Zuruckmelden der Ergebnisse der vorher 
durchgefuhrten Operationen gewahrleistet . GemaS der Semantik 
der Socket-Programmierschnittstelle ist es erforderlich die 
Schliefiung eines Sockets nach Beendigung seiner Benutzung 
durchzufuhren und dies erfolgt mit Verwendung des 
Systemaufrufes close oder shutdown, das heifit Systemauf ruf e, 
die in einem blockierenden Modus zu realisieren sind. 



Ein Problem der durch die vorliegende Erfindung 
gewahrleisteten Optimierung ist die semantische Anderung der 
Ruckgabewerte bei den nicht-blockierenden Socket-Auf ruf en, 
auf deren tatsachliche Ausfuhrung nicht gewartet wird. Aus 
diesem Grund ist es erforderlich, dag von dem Pipelinemodul 
15 die Kontrolle uber die durchgef ahrten Systemauf ruf e mit einer 
entsprechenden Meldung an die Anwendung sichergestellt wird, 
Schlagt beispielsweise der Auf ruf connect fehl, well 
beispielsweise die angesprochenen IP-Adresse auf grund eines 
Netzwerkfehlers nicht erreichbar ist, so erfahrt das 
20 Pipelinemodul von dem entsprechenden Fehler erst nach Empfang 
des zugehorigen Riickgabewertes und nachdem dieser Aufruf fur 
die Anwendung bereits als erfolgreich abgeschlossen gilt. Der 
Ruckgabewert wird jedoch nach dem Empfang in dem 
Pipelinemodul abgespeichert und bei einem nachsten 
25 Systemauf ruf der Anwendung mitgeteilt. Die bevorzugte 

Realisierung sieht vor, daiS die Mitteilung direkt bei dem 
nachfolgenden Systemauf ruf erfolgt. Hiermit wird die 
moglichst fruhe Fehlermeldiing gewahrleistet. Die Rechnerzeit 
fur die Uberprufung der ausstehenden Fehlermeldungen ist 
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geringer als die Ubertragungszeit im GSM, deswegen kann eine 
Uberprufung der in einem Pipelinemodul vorhandenen 
Ruckgabewerte ohne groSen Aufwand realisiert werden. 

5 Eine andere Moglichkeit ist die Meldung der auf getretenen 
Fehlern bei dem nachsten Systemauf ruf , der im blockierenden 
Zustand durchgefuhrt wird. 

Diese Ausf uhrungsf ormen werden von der Implementation 
10 abhangen. In beiden Fallen ist es jedoch notwendig, die 

Ausfuhriing des letzten Systemauf ruf es in einem blockierenden 
Zustand zu realisieren. 

Die "verspatete" Fehlermeldung fuhrt bei den bekannten 
15 Anwendungen zu keinen Problemen, da diese auch bei dem TCP 
darauf vorbereitet sind, daE jederzeit Fehler auftreten 
konnen . 

Die Realisierung der Erf indung wird im folgenden anhand eines 
20 Ausfiihrungsbeispiels und der Figuren 3a und 3b naher 

erlautert. Die Figuren stellen einerseits die ausgefuhrten 
Systemauf ruf e dar, die von einer Anwendung initiiert werden. 
Dies ist auf der linken Seite der Figuren dargestellt. Die 
rechten Seiten der Figuren stellen die Netzwerkoperationen 
25 dar, mit denen die Durchfuhrung der entsprechenden 
Systemauf ruf e eingeleitet wird. 

Das Ausfiihrungsbeispiel gemaS Figur 3a stellt einen 
Verbindungsaufbau dar, der im Protokoll HTTP 1.0, RFC 1945, 
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im Stand der Technik durchgeftihrt wird. Bei diesem Protokoll, 
das zum Abruf von WWW-Seiten eingesetzt wird, wird fiir jedes 
Objekt eine separate Verbindung aufgebaut. Eine Verbindung 
wird gemag Figur 3a mittels eines ersten Aufrufes connect 
5 realisiert. Folglich werden die Daten, zvim Beispiel ein 

Objekt, mittels eines ersten und zweiten Aufrufes, send und 
recv, angef order t und ubertragen und anschlieBend die 
Verbindung mittels eines weiteren Aufrufes close abgebaut. 

10 GemaS der vorliegenden Erfindung wird ein umgewandelter 
Systemaufruf nicht direkt tiber ein Ubertragungsmedium 
tibermittelt, sondern er wird zuerst dem Pipelinemodul 
iibergeben, das ftir die Aufarbeitung des Systemaufruf es 
zustandig ist. GemaS Figur 3b wird im ersten Schritt ein 
15 erster Systemaufruf connect initiiert, der von dem 

Pipelinemodul als ein nicht-blockierende Systemaufruf 
interpretiert wird. Dies ist derart dargestellt, dag das 
Pipelinemodul einerseits die entsprechende Netzwerkoperation 
an den Server versendet und gleichzeitig der Anwendung 
unmittelbar ein Resultat beziiglich des Systemaufruf es 
tibergibt ohne auf das tatsSchliche Resultat der im Server 
durchgeftihrten Operation gewartet zu haben. Die unmittelbare 
iibergabe des Resultates ist durch einen direkt 
zuruckkehrenden Pfeil gekennzeichnet . 



20 



25 



Diese Methode fiihrt dazu, dafi die Anwendung nicht in einen 
blockierenden Zustand versetzt werden muss, der eine ganze 
RTT (Round Trip Time) dauert, sondern unmittelbar nach 
Empfang des Resultats mit der Ausfuhrung der folgenden 
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Schritten fortgefahren wird. GemaS Figur 3b ist es ein 
weiterer Systemauf ruf send, der auf die gleiche Weise wie der 
erste Systemauf ruf connect behandelt wird. Als nachster 
Systemauf ruf erfolgt der Systemauf ruf recv. Dieser wird 
5 ebenfalls zuerst an das Pipelinemodul ubergeben, das diesen 
Systemauf ruf als einen blockierenden Auf ruf identif iziert , 
denn es werden als Ruckgabewert Daten erwartet . Aus diesem 
Grund kann das Pipelinemodul kein unmittelbares Resultat an 
die Anwendung zuriicklief em, sondern es wird auf das Ergebnis 

10 des tatsachlich im Server durchgeftihrten Systemauf ruf s 

gewartet. Aufgrund der Tatsache, daS die Operationszeit eines 
Rechners im Vergleich zu der Ubertragungszeit einer 
Netzwerkverbindung, insbesondere einer GSM-Verbindung , 
geringer ist, erfolgt die Versendung der Netzwerkoperationen 

15 unmittelbar hintereinander . Aus diesem Grund werden in diesem 
Fall zwei RTT gespart, denn es wird nicht auf das Resultat 
der Systemauf ruf e connect und send gewartet. Dieses Resultat 
wird zusammen mit dem Resultat des Systemauf ruf es recv 
zuruckgeliefert . Das Verschicken der Netzwerkoperationen 

2 0 direkt hintereinander ist in Figur 3b mittels eines breiteren 
Pfeiles dargestellt, der die entsprechenden 
Netzwerkoperationen gemafi der Reihenfolge des Versendens 
en thai t . 

25 Charakteristisch fur die Erfindung ist ihre Unabhangigkeit 
von einer Transportplattf orm. Denn die Funktionalitat ist 
ebenfalls gewahrleistet , wenn ein anderes Transportprotokoll 
als T/TCP zugrundeliegt . Im Falle von T/TCP werden die beiden 
Systemauf ruf e, connect und send als ein sogenannter sendto 
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Systemaufruf interpretiert . Die Veirwendung dieses anderen 
Protokolls andert jedoch nichts an der gesamten Ersparnis 
bezuglich der notwendigen RTTs, deren Anzahl in dem 
aufgeftihrten Beispiel von 3 auf 1 reduziert wird. 

Im folgenden wird die erf indungsgemafie Vorrichtung gemafi des 
Patentanspruches 16 naher erlautert (ohne Figur) . Bei der 
erf indungsgemaSen Vorrichtung zu einer schnellen Durchf uhrung 
von Netzwerkoperationen uber ein Netzwerk mit hohen 
Verzogerungszeiten wird fiir einen Systemaufruf mit einem 
Ermittlungselement der Ausf uhrungsmodus des Systemaufruf es 
ennittelt, Hierbei wird zwischen einem blockierenden und 
einem nicht-blockierenden Zustand unterschieden . Mit Hilfe 
von Umwandlungsmitteln wird ein Systemaufruf in eine 
Netzwerkoperation umgewandelt. Der Sender versendet die 
Netzwerkoperationen an eine kommunizierende Einheit. Die 
Resultate, der bei einer Kommunikationseinheit durchgef uhrten 
Netzwerkoperation werden bei der die Netzwerkoperation 
initiierenden Einheit mit einem Empf anger empfangen. Die 
empfangenen Resultate werden in einem Speicher gespeichert 
und mit einem Bearbeitungs element gemaS des enthaltenen 
Wertes entsprechend bearbeitet. GemaS Patentanspruch 18 wird 
eine Unterscheidung zwischen negativen und positiven Werten 
vorgenommen . 

Im Falle eines nicht-blockierenden Systemaufruf es wird nach 
Auslosung der entsprechenden Netzwerkoperation auf das 
Ergebnis des in einer Partnerinstanz ausgef uhrten 
Systemaufrufes gewartet ohne hierbei die Ausf uhrung der 
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Anwendung zu blockieren. Dies wird mit Elementen zur 
Realisierung eines solchen Zustandes realisiert. 

Die Realisierung der Erfindung basiert darauf , daS ein 
5 zusatzliches Modul, das oben genarmte Pipelinemodul , 

unterhalb der Socket-Programmierschnitts telle vorgesehen 
wird. Aus diesem Grund muss die Implementation der Erfindung 
auf der Ebene des Betriebssytems realisiert werden unter 
Berucksichtigung der unter schiedlictien Ausf uhrungsf ormen der 

10 verschiedenen Betriebssysteme , Die Grundidee der Socket- 
Programmierschnittstelle ist jedoch ihre 
Protokollunabhangigkeit . Deswegen wird in den meisten 
Betriebssystemen eine interne Sof tware-Schnittstelle mit dem 
Zweck der Einbindung eines zusatzlichen Protokollmodules zu 

15 der Socket-Programmierschnittstelle vorgesehen, was die 
Realisierung der Erfindung erleichtert. 

Die Implementation der Erfindung wird im folgenden anhand des 
Betriebssystems Windows als Beispiel und der Figur 4 naher 
2 0 erlautert. 

Die Figur 4 stellt einen Protokollstapel mit den involvierten 
Instanzen dar. Die direkt benachbarten Instanzen, Anwendung, 
Winsock2, Pipelinemodul und Transport Protokoll kommunizieren 
25 miteinander, was durch. die Pfeile gekennzeichnet ist. Die 
Kommunikation der benachbarten Ebenen erfolgt durch eine 
definierte Sof tware-Schnittstelle , beispielsweise erfolgt die 
Kommunikation der Instanz Anwendung und der Instanz Winsock 2 
durch die Socket-Programmierschnittstelle, die im 
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Betriebssystem Windows den Namen Winsock API trSgt. Die 
Software-Schnittstelle Winsock SPI (Service Provider 
Interface) , die in "Windows Sockets 2 Service Provider 
Interface", Revision 2.2.2, Microsoft, August 1997 naher 
beschrieben ist, wird zur Kommunikation zwischen der Winsock 
2 Ebene und dem darunter implementierten Protokoll, in diesem 
Fall dem Pipelinemodul , benutzt. 
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1, Verfahren zu einer schnellen Durchfuhrung von 
Netzwerkoperationen liber ein Netzwerk mit hohen 

5 Verzogerungszeiten mit einem Modul fur eine Bearbeitung 

eines Systemauf ruf es einer Anwendungsebene und fur eine 
Auslosung von Netzwerkoperationen einer Netzwerkebene mit 
folgenden Schritten, 

- tibergabe des Systemauf ruf es an das Modul, 

10 - Ermittlung eines Ausf uhrungsmodus des Systemauf ruf es mit 

Unterscheidung zwischen einem blockierenden und einem 
nicht-blockierenden Ausf uhrungsmodus , 

- unmittelbare Ruckgabe eines logischen Wertes an die 
Anwendungsebene und Auslosung einer Netzwerkoperation im 

15 Falle eines nicht-blockierenden Ausf uhrungsmodus . 

2 . Verfahren nach Anspruch 1 bei dem die Netzwerkoperation zu 
einer Partnerinstanz ubertragen wird, die mit einer die 
Netzwerkoperation auslosenden Einheit in Kommunikation 

20 steht. 



3 . Verfahren nach Anspruch 2 bei dem die in der 

Partnerinstanz empfangene Netzwerkoperation in eine 
Operation umgewandelt wird, diese durchgefuhrt wird und 
25 ein Resultat der Operation an die Einheit, die die 

Netzwerkoperation ausgelost hat, zuriickgesendet wird. 
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4 . Verf ahren nach einem der Anspruche 1 bis 3 bei dem eine 
Bearbeitung des empfangenen Resultates einer Operation in 
dem Modul realisiert wird. 

5 . Verf ahren nach einem der Anspruche 1 bis 4 bei dem ein 
nicht-blockierender Systemaufruf nach Auslosung der 
Netzwerkoperation in einen Zustand versetzt wird, in dem 
auf ein tatsachliches Ergebnis des in einer Partnerinstanz 
ausgefiihrten Systemaufruf es gewartet wird ohne Blockierung 
der Ausfuhrung der aufrufenden Anwendung. 

6. Verf ahren nach einem der Anspruche 3, 4 oder 5 bei dem die 
empfangenen Resultate sich auf einen nicht-blockierenden 
Zustand beziehen und einen logischen Wert haben oder diese 
ein Resultat eines in der Partnerinstanz durchgef uhrten 
blockierenden Systemaufruf es sind. 

7 . Verf ahren nach einem der Anspruche 3 bis 6 bei dem die 
empfangenen Resultate bei einem nicht-blockierenden 
Ausfuhrungsmodus zwischengespeichert werden. 

8 . Verf ahren nach einem der Anspruche 1 bis 7 bei dem die 
logischen Werte entweder einen logisch positiven oder 
einen logisch negativen Aussagewert haben. 

25 

9 . Verf ahren nach Anspruch 8 bei dem die logisch negativen 
Ergebnisse bei der Durchfiihrung des folgenden 
Systemaufrufes der Anwendung in Form eines logisch 
negativen Riickgabewertes mitgeteilt werden. 



5 



10 
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10. Verfahren nach einem der Ansprtiche 3 bis 9 bei dem, bei 
einem nicht-blockierenden Systeitiauf ruf , im Falle von nicht 
ausstehenden negativen Resultaten vorheriger Aufrufe, 

5 immer ein logisch positiver Wert an die Anwendung 

zuruckgelief ert wird. 

11. Verfahren nach einem der Ansprtiche 1 bis 10 bei dem der 
letzte Systemaufruf einer Verbindung in einen 

10 blockierenden Zustand gesetzt wird, um ein Zuriickmelden 

der Ergebnisse der vorher durchgef uhrten Operationen zu 
gewahrleisten . 

12 . Verfahren nach Anspruch 1 bei dem die blockierenden 
15 Systemaufruf e auf eine bekannte Weise realisiert werden, 

in dem auf das Resultat des in einer Partnerinstanz 
ausgef uhrten Systemaufruf es gewartet wird. 

13 . Verfahren nach einem der Anspruche 1 bis 12 bei dem die 
2 0 Systemaufruf e Socket-Systemauf ruf e sind. 

14. Verfahren nach Anspruch 13 bei dem die Socket- 
Systemauf ruf e eine Programmierschnittstelle fur ein 
Betriebssystem bilden. 



25 



15. Verfahren nach Anspruch 1 bei dem das Modul ein 
Pipelinemodul ist. 
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16. Vorrichtung zu einer schnellen Durchf lihrung von 
Netzwerkoperationen uber ein Netzwerk mit hohen 
Verzogerungszeiten mit einem Modul fur eine Bearbeitung 
von Systemauf ruf en einer Anwendungsebene und fur eine 
5 Auslosung von Netzwerkoperationen einer Netzwerkebene mit, 

- einem Ermittlungselement zur Ermittlung des 
Ausf uhrungsmodus eines Systemauf ruf es , 

- Umwandlungsmitteln, das den Systemauf ruf in 
Netzwerkoperationen umwandelt, 

10 - einem Sender zum Versenden von Netzwerkoperationen, 

einem Empf anger zum Empfangen von Result at en der 
durchgefuhrten Netzwerkoperation, 

- einem Speicher zum Speichern von empfangenen Resultaten, 
einem Bearbeitungselement zur Bearbeitung der 

15 empfangenen Resultate. 



17 . Vorrichtung nach Anspruch 17 mit Elementen zur 
Realisierung eines Zustandes, in dem nach Auslosung der 
Netzwerkoperation auf das Ergebnis des in einer 

2 0 Partnerinstanz ausgefuhrten Systemauf ruf es gewartet wird 

ohne Blockierung der Ausfuhrung der aufrufenden Anwendung. 

18. Vorrichtung nach Anspruch 18 bei der das Mittel zur 
Bearbeitung der empfangenen Resultate die Unterscheidung 

25 zwischen negativen, positiven Werten vornimmt . 
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Zu s ammen f a s s ung 



Die Erfindung betrifft ein Verfahren und eine Vorrichtung zu 
einer schnellen Durchfiihrung von Netzwerkoperationen iiber ein 
5 Netzwerk mit hohen Verzogerungszeiten mit einem Modul fur 

eine Bearbeitung von Systemauf ruf en einer Anwendungsebene und 
fiir eine Auslosung von Netzwerkoperationen einer 
Netzwerkebene . In diesem Modul wird eine Unterscheidung 
zwischen einem blockierenden und einem nicht-blockierenden 

10 Ausfiihrungsmodus durchgef lihrt , Ein nicht-blockierender 

Ausfiihrungsmodus bedeutet, daS der betrachtete Systemauf ruf 
als Ergebnis einen logischen Wert an die Anwendung 
zurucklief ert , der besagt, ob der Systemauf ruf erfolgreich 
durchgef tlhrt wurde. In diesem Fall sieht die Erfindung vor, 

15 beim Aufruf eines nicht-blockierenden Systemauf ruf es 

unmittelbar einen logischen Wert an die Anwendung zu liefern 
ohne auf das tatsachliche Resultat der in der 
kommunizierenden Partnerinstanz durchgef uhr ten und dem 
Systemauf ruf entsprechenden Operation gewartet zu haben. Die 

2 0 Behandlung der Resultate der tatsachlich durchgef lihrten 

Operation erfolgt zu einem spateren Zeitpunkt. Mit dieser 
Modif izierung werden die Netzwerkoperationen, die aus den 
Systemauf ruf en abgeleitet werden, schneller durchgef lihrt , 
denn es wird nicht bei jedem Aufruf auf das tatsachliche 

25 Resultat gewartet und dies impliziert ebenfalls die 

Reduzierung der Anzahl der notwendigen RTTs (Round Trip 
Time) . 
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